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An Important Note regarding version 1.0B4: 


The following is Revision 1.0B4 of the Xanadu/Server™ System Overview. This 
working document is being provided at this time in order to give you an early 
look at the components of a Xanadu system — it is guaranteed to change. 
Nevertheless, it will remain useful as a starting point in understanding the Xanadu 
development process. 


This revision is distnguished from previous versions primarily by a reorganization 
of the material; most of the content remains unchanged. There sull is no material .- 
on Sensors and very litle on Endorsements — these will be added in future 
revisions. The appendices remain under construction. The section on 
Sponsorship has been removed and will be replaced in a future revision. 


As in previous versions, the focus remains on the Application Program Interface 
and in particular on the Manipulator Interface, a mid-level entry point to the 
Xanadu system that provides all of the power necessary to enable developers to 
take full advantage of the features of the Server. 


The High-Level-Xanadu-Interface CHLX]), an even higher level interface to the 
Server, is also available and will be documented in upcoming versions of this 
overview. HLXI will provide most—but not all—of the power available at the 
Manipulator Interface level, but will be considerably easier to use. Developers 
who want the full power and flexibility of the system will continue to use the 
Manipulator Interface to build their applications; most Developers, however, will 
prefer the much simpler access available through HLXI. 


All credit for the wonderful ideas herein go to the members of the Xanadu 
development team. Particular thanks go to Eric Dean Tribble, Mark Miller, Ravi 
Pandya, Hugh Hoover, Roger Gregory, Mare Suegier, Michael McClary, Eric Hiuil, 
Roland King, Bill Richard, Eric Drexler, and John Walker. And of course, Ted 
Nelson. I’d also like to thank Sue Schumaker for her wonderful support 
throughout this project. All responsibility for errors, typos, and fuzziness, of 
course, remains mine. 


BOD: Perez 
June 5, 1990 
Palo Alto, California 








This page left intentionally blank, too’ 


Table of Contents 


70, {Gi - sS! 26) Or 4S 8 ees 50S (8 Te AS ee GO SOL a Oe ee. OL ea Or SO 8 Ce ew OR 18. OM 7) BO 8 Oa OS LO er Ce ¢ 
e "6@ Se 6" “© 8 ‘e820 ‘= s. (8) ye) @ 6 (6. 8-6) 4 6° Ss 64, 8 6S Te 
9.85 S'S) (6) Le PW 86> *:a Os 8. 6 Oe) a 8) 8 Os GO Tey OS" 8 6. Oe Oe! 56> 16) See 8 


a0 188 68 OS 1 8 Ae, SUS: Se Ok Sw 7 -S'P 167 0 20) Ve. 10. 2O) 0 ee, Ve Ue Ve 36. 16. (22 1S, 6. Se 


Fundamental Components of the Xanadu /Server 
Xanadu Documents 
pte iete la a ab! 2) sce ieee tera ete a NORE ROSE AC ewe ee eee OG EEE Ne Get Ce ORT 
peat 8c) Co ORE eR Ree ee ee nee OY er gE eee ee eee ee 
Version Control & Version Comparison 


wT ey (Or 8 TO, 67 8 SR OI U8) Je. 8 SOL (e166) @. $8), 6 WENO O76 Oe Ot Oe SO" AG TO 8S VO eS Se: 


Oe es a Se 8 wD OO LO, OS SO r ea ce) Se IS Oe TS 6 


PE POCTAt iy NCE Ae Pay Cloner aes, eR eee ra cee eee 
ae TIOGUIOOIS cc Lime Level vr taut. ue ea ee Oe tg ne te ate 
The Xanadu Document Model 
OV Se CCG le cee eee Sener eet ate eee eae 
Document Hierarchies 

SN GVe Ges ||) Aaa Nae ne eat a enna ah | er ieee ann oh oP era ee Mirae ie ee elec ee err 
The Separation of State: Berts & Stamps 
gt B IEA OU 6) cA mr We ae ee owe ered ee Oho wn en any ae ars See EN ye ree 
Authorship & Endorsement 
BF Gye @ Uh Stl gb ea ane or ede CON oe ae RIE ee a RS a cL ee hI ee eee aa? 
Creating Links 


Oo SIG 6 eo OSS FR, IO OS OL 6, fe es Oe 8 Oe Or ee LO TO ee Ie as, he 
CR OO) Ca OT 8 6) (OO? (R18 58 6 OR 96) Ce 2 6 Vis -6. 86 a 64-8 UO °6 ee eS 8 ter “es 
oe, “e736: a) “@ (a) “ae FO Be Fe Ceo 8. ee. ee) eo 
Oe 6) a 6 - ‘eee. 96) 86, Cee) (46, 8) ie, 'e, Je. 8) @ (6. é. Ja, le, ie ae Je -el ce 


8) 36) oS Oh +67 6) 6". kee Or FO. Oe 6, Se FON ey 1 Lo Fe BP Oe” el ner et ie) 6, “84 8) See) oY (8 el “Se. “eit @ “6. 
nc i en ee Te. eee een le ees ee TS on a Le, Se I len ee ee, See Yee Ane eee Ieee YY | 


Sensors 


O° 6) 1S 1S) 5671-0. 148, CRIS) 16 ROL Oye” 80 Te er ver” Werte? Se: Od a £6) “O46 8 US CO Tee a 6 eS) ee 6 ae." @; 78? “60 ee? (©. “er [0.76 


Sie hey O8y Os CR er OL ie, pea 8) Oe OTS. 8, ye eh te ee Le eC Oe Oe > Oe ee Oe ew, OO. 8. Vee Oy eet Os) 6) By et Le Be oe Se Cres 


oe, 1a) 787 er VO" eh GF ar Tae 18 ee ee Sa) er Tee: Ot 6." e) 6,) 6.) 608. 0, 6. 6)! Oe. (ey SO a 8 a Or Oe Se ey Oy Oe Le. Ve ce 


Bi SEe UC SBA g @ oon Mes yee Ue pe oe ace ee ROU Ea creo eT Pa eee 
Using Waldos to Manipulate Links 
Using Waldos to Follow Links 


pel Varta cd cap nab rchtl Oy @ prep ici! os € & Beat me anne Ham OO Ree Beeson oan Nn kare Wee eet Re SETA Te 
| Car Ree oe ce te ne ane ee AiR a SRT Ce aT ene Pe eS Toes 
Control Authority and Read Authority 


KeyMasters & Club Managers 
A Final Note on Permissions 


wi 8. 49, 8)”, 8, ee! COM ee. Sel ey a6) cee let a, Jey allele a: 6. |e we 
ee ve) 6" a= er. Se re, 8 Le) en a8 [6 ‘6. “65 46) tel Ce 96> a. 50: 58) fe with Gis, Te. be) Mer Ce 


ee, 6 8. ee Oem CT ee Eee oe we ea. PO heh ae. 56) 6.8 8m 8m te, iat oe) Ee ae a 


Xanadu/Server System Overview Rev 1.0B4 





NM bh Re Re 


ON U1 U1 oS AN 


Fave 4 


Yet another page left intentionally blank. 


Xanadu/Server System Overview Rev 1.0B4 Passed 








Preface 


This document describes the Xanadu/Server environment and should be your 
starting point in learning the system. It’s intended as a high-level technical 
introduction to the system as a whole, encompassing both architectural aspects of 
the Server itself, and programming conventions adopted by Xanadu Operating 
Company, Inc. for the development of application programs that access the 
features of the Server. After reading this document, you should have a better 
understanding of the interrelationship of the various components of a complete 
Xanadu/Server system, as well as a basic understanding of how application 
programs interact with this system. 


This information will provide you with a baseline foundation for understanding 
the development of Xanadu applications. In order to actually write those 
programs, however, you’ll need to read additional reference materials available 
through the Xanadu Developer Program, including most of the documentation 
included with the Xanadu Developer Toolkit. 


This document assumes no prior knowledge regarding the Xanadu/Server, but 
does assume a minimal familiarity with hypertext terminology and its idioms. If 
you are unfamiliar with hypertext, or simply want to refresh your understanding 
of the subject, see Appendix D, “Suggested Readings on Hypertext’ 


Introduction to the Xanadu/Server 


Xanadu/Server is an information management product that offers fundamentally 
new ways of organizing and manipulating information. Using state-of-the-art 
hypertext techniques, the Server enables users to create document-based 
information pools of unlimited size, and provides users with the ability to easily 
discover and track relationships between individual documents. Xanadu/Server 
makes it easy to create arbitrary relationships between documents including, for 
example, annotations to drawings, citations to further references, or comments 
from multiple editors concerning a particular document. 


The information pools managed by the Server have no inherent size constraints 
and can consist of documents containing any form of structured or unstructured 
data, including unindexed text, graphics, sound, and all other forms of digital data. 
Efficient access to this data is assured by the proprietary algonthms used by the 
SEIVer. 
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A Client-Server Architecture 


A complete Xanadu system is based on a Client-Server architecture that segments 
its work into two separate tasks: the storage and maintenance of a growing 
information pool/and the presentation of this information to end-users. The | 
component that stores and maintains the information itself is the Xanadu/Server, 
also known as the backend. The responsibility for presenting this information to 
end-users resides in client frontend applications, or frontends. This document 
will use the term “backend” or “Server” to refer to the Xanadu/Server, and 
“application” to refer to a client frontend application. 


The backend is responsible for the storage, maintenance, and retrieval of all 
information in the system. This responsibility includes the maintenance of all 
complex relationships among the data, as well as support for editing operations 
on that data. Additionally, the backend enforces user-designated permission 
boundaries using a comprehensive system of individual and group permissions. 
Data integrity is a critical element in the evaluation of any network server; 
accordingly, a great deal of work has been done to insure the integrity of data 
residing on the Xanadu/Server. 


Xanadu applications run on any,of the popular personal computers and 
workstations, and span the entire range of application possibilities, including 
text-processing, image-processing, Electronic Mail, and CAD. These applications 
can resemble their non-Xanadu counterparts in every way, but are written to take 
particular advantage of the capabilities of the Server. 


Xanadu client applications communicate with the Server using a published 
interface protocol called the “Frontend-Backend Protocol’, or “FEBE Protocol “ 
(pronounced fee-bee). For a list of network architectures currently supported, 
see Appendix A, “Hardware & Software Environments Supported”. 


A Layered Architecture 


The Xanadu system is a rich, interactive environment, operating across several 
distinct layers, each of which provides an important level of service to the others. 
The three fundamental layers are: 


1) The User imteriace laver- 
2) The Program interface layer: and 
3) Tne Ssuptenanean laver. 


A typical Xanadu frontend application spends most of its ume doing one of two 
things: 1) interacting with end-users, and 2) manipulating Xanadu documents. 
These operations correspond to procedures found in the User and Program 
Interface layers, respectively. Except in extraordinary situations, frontend 
application developers will be concerned with only these two layers. 
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The User Interface layer consists of the routines and data structures used by 
developers to maintain the communication between an application and its end 
users. Because of the intimate association of these elements with user-interface 
issues that are necessarily application-specific, the implementation of this layer is 
left entirely to developers according to the requirements of their application. 


Some platforms (e.g., Macintosh, Windows, Presentation Manager) provide their . 
own display and presentation routines, and most developers will use these in the 
creation of their application’s user-interface. However, it is still necessary in such 
cases to have a set of tools that can translate the various Xanadu data structures 
into objects understood by the chosen display routines, and vice-versa. The 
Xanadu Developer Toolkit includes libraries which provide these translations and 
which link into standard C programs; this enables C programmers to use esta 
existing user-interface libraries in their Xanadu applications. 


The Xanadu Developer Toolkit also provides object-oriented libraries and tools 
for those developers using C++ or Smalltalk, including a powerful suite of 
machine-independent text-editing routines. We expect many C++ programmers 
will use this code as a basis for developing platform-independent text-display 
routines, Dut you’re of course free to write your own, 


The Program Interface layer provides the primary application interface to the 
Server, and. contains all of the system calls necessary for the creation and 
manipulation of Xanadu documents. A level of abstraction is provided through 
which the underlying magic of the system can be visualized and accessed. By 
insulating software developers from the underlying data engine, easier access is 
provided along with higher assurances of future compaubility. 


The Subterranean Layer is in fact made up of several separate layers providing 
low-level services to and from the hardware and the upper layers. These 
subterranean layers are implemented in the backend for high performance, and 
are not directly accessed by frontend applications. For additional information on 
ine Sspecitic Services Offered, contact Xanadu Téchnical Support. 
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Fundamental Components of the Xanadu/Server 


The following material describes briefly four fundamental components of the 
Xanadu system: 


1) Xanadu Documents; 

2) Xanadu Links; 

3) Sensors; 

4) Version Control & Version Comparison. 


Additional information on each of these subjects can be found in the section 
entided “The Program Interface Layer’, immediately following this Introduction. 


Xanadu Documents 


Unlike ordinary electronic documents, which enforce a distinction between their 
contents and the world outside their boundaries, Xanadu documents are “soft- 
edged”, with permissive boundaries that promote an easy and intimate association 
with other documents in the information pool. The key to understanding this 
easy association is in understanding the notion of virtual documents. 


Ordinary electronic documents frequently include duplicated instances of the 
same underlying elements (e.g., illustrations created in a graphics program and 
later copied into a word-processing document, or text found in one paragraph 
and later copied into another). The Xanadu/Server avoids this kind of redundancy 
by making it an attribute of all data elements in the information pool that they can 
be shared across any number of documents. A virtual copy of a Xanadu 
document, then, is simply another Xanadu document that references the same 
underlying data as the “original document”, without having to replicate any of the 
underlying data. 


The elements making up Xanadu documents do not necessarily share any logical 
or physical proximity on the Server. The actual physical and logical location of the 
data is transparent and irrelevant to the end-user, who just sees a “document” 
composed of several parts. 


The benefits of virtual documents are significant: increased storage and retrieval 
efficiency without the overhead of data redundancy. 
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Xanadu Links 


Links are the primary means by which end-users identify relationships within 
their information pool. By creating a link from one document to another, a user 
asserts the existence of a relationship between the two documents, and provides 
other users with the ability to identify and track that relationship. The number 
and kind of relationships supportable in an application are entirely up to the 
application developer, since the Xanadu/Server offers the ability to create an 
unlimited number of different link types. 


Link typing allows end-users to impose relevancy filters on their examination or 
retrieval of Xanadu documents and links. Documents of great interest on a Server 
might generate hundreds, or even thousands, of links; typically, users do not want 
to see all of these links and are interested in only a subset of link types. Examples | 
of link types include “Comment Type” Cinks to simple annotations), “Criticism 
Type” (inks to material critical of the linked material), or “Author Type” (links to 
other works by the same author). | 


Unlike most hypertext links, Xanadu links are omni-directional; they can be 
traversed forward or backward without restriction. This omni-directionality 
provides complete access to @// linked material in an information pool. This is 
true even where a user has no previous knowledge that a link exists. Whereas 
traditional hypertext links allow users to branch forward to suggested further 
readings, for example, the Xanadu/Server provides the unique capability of tracing 
backward to all material referencing a given document. This BackReference 
operation is a powerful feature that gives Xanadu users the ability to create 
exhaustive, efficient cross-referencing of all related materials. 


Xanadu links can attach to material of varying granularity, from large chunks of 
data (é:9., a complete book) to very small elements (-single character of text, or a 
single bit in a bitmap). Additionally, Xanadu links can attach to collections of non- 
contiguous sections of material and treat these non-contiguous sections as a unit. 


Sensors 


The Xanadu/Server offers end-users a unique way to monitor the dynamic state of 
their environment: Sensors. Sensors are objects which end-users can create and 
then attach to the various documents or elements in their information pool. 
Sensors can be defined to wait for a particular set of circumstances to occur, and 
tien take some specific action upon that occurrence: 


Sensors might at first glance resemble a simple alert mechanism based on remote 
procedure cals and imtactiney cam pe used im (his stmpic iasnion (e:c 2 1iser 
could attach a sensor to a document and ask to be notified whenever anyone 
attempted to edit the document). However, because of their integral relationship 
with the other Xanadu components, sensors provide a powerful mechanism for 
monitoring qualitative changes in the information pool. 
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For example, a user could attach a sensor to a document asking to be notified in 
the event that anyone at the Executive Staff level attaches a link of type “Criticism” 
to “paragraph 10”. As another example, a sensor could be attached to an 
electronic mailbox alerting the user to the existence of any new mail on the 
subject of a proposed ERS, originating from any member of the Engineering 
department. In fact, using Xanadu’s links, sensors, and virtual documents, a 
complete electronic mail system of unprecedented power could be constructed. 


Version Control & Version Comparison 


Most current-generation software is designed to be used by a single user working 
alone on a particular document, or set of documents. Such applications actually 
inhibit the collaborative process by making it hard for others on the network to 
integrate their feedback, criticisms or suggestions. In a typical scenario, a single 
writer creates an original document and then circulates physical copies of the 
document to others in his work group for their suggestions. The other writers 
have the option of scribbling hand-written notes on the margins of their copies, 
or creating separate new documents containing their individual comments. In 
either case, the original author faces at least two problems: the accumulation of 
largely redundant data, and the integration of the solicited feedback with the 
contents of the original document. Notice also the natural tendency to read 
feedback documents in a linear fashion and thereby lose the impact of individual 
points made out of context. 


A common solution to this problem uses software-based version comparison. In 
this scenario, the author of an original document publishes an electronic copy of 
his work and then solicits suggestions for changes from others on the network. 
His associates copy the work to their individual workstations, edit their copies, 
and then submit their edited copy back to the original author. The original author 
then uses version comparison software to identify the differences between his 
Original document and each of the submitted edited versions. The use of version 
comparison software helps isolate the various differences, but there remain the 
dual problems of accumulating redundant data and the integration of multiple 
edits. 


Notice also the storage and retrieval inefficiencies introduced by this latter 
approach. Current generation version control software requires that each of the 
separate versions of a document be available for comparison; typically, these 
different versions are stored using one of two techniques. In the first case 
complete copies are kept of all versions. This results in fast retrieval of individual 
versions, but is manifestly inefficient, particularly where the number of potential 
changes and users is significant over the life of a document Gwhich might be 
source code, a technical manual, or some other shared work). — 
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The second technique saves a copy of the original document and thereafter saves 
only the individual changes to the document. Reconstruction of a particular 
version is accomplished by traversing the tree of changes and building the 
document on the basis of the difference between the original and the changes 
existing at the point of the desired version. This “delta-storage” technique has its 
own inefficiencies since any given reconstruction might be built upon previous 
reconstructions; as new versions are created, the time to reconstruct any 
particular version grows dramatically. : 


By using an entirely different approach based on the availability of virtual 
documents, the Xanadu/Server avoids each of the preceding problems. 

Unlimited multiple versions of a particular document can be stored easily and 
retrieved quickly without the burden of data redundancy, and without the need for 
time-consuming linear delta reconstruction. 


The efficiency of the Xanadu/Server version compare technology makes it 
possible to use a new model for document development in a multiple editor 
environment. Under this model, multiple editors create new versions of 
documents easily and inexpensively using virtual documents, and then use version 
compare software to converge their efforts. This diverge/converge model 
replaces the more common mutual exclusion model, where multiple editors are 
physically locked out of documents currently being edited, and provides multiple 
editors with the freedom to quickly and easily spin off new versions while 
retaining the ability to easily integrate their efforts. 
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The Program Interface Layer 


This section describes the Program Interface layer and its two chief components, 
the Documents & Links Level, and the Manipulator Interface. You'll want to read 
this section if you’re interested in learning about the components making up a 
Xanadu frontend application. 


The section entitled “The Documents & Links Level” details the various 
characteristics of Xanadu documents, links, and sensors, and provides the 
foundation for understanding how to use these objects in your applications. You 
should read this section first. 


The “Manipulator Interface” section describes the programming model used to 
build Xanadu frontend applications. You should read the “Documents & Links” 
section first to understand how to use the Manipulator Interface to accomplish 

specific application objectives involving documents, links, or sensors. 


Finally, the Section entided “The Permissions System” describes the Xanadu 
Gocumient security system, and can be fread 2t.any time: 


The Documents & Links Level 


Links are a fundamental component in any hypertext system. However, because 
of the intimate association between Xanadu links and the unique document model 
used by the Xanadu-Server, an understanding of the Xanadu document model is a 
prerequisite to understanding Xanadu links. Accordingly, the next section begins 
with a description of the Xanadu document model, and follows with a discussion 
of links and sensors. 


Applications do not directly manipulate Xanadu documents, links, or sensors; 
instead, they use objects called Manipulators. Manipulators are session-level 
objects that provide the protocols used to interact with each of the Xanadu 
objects. Most Xanadu frontend application code consists of messages sent to and 
from the various kinds of Manipulators; the Manipulator Interface documents 
these messages. In order to take full advantage of the Manipulator abstraction, you 
should first have a good understanding of the underlying Xanadu objects and their 
interaction with each other. 


This section describes the following features of the Document & Links Level: 
1) The Xanadu: Document Model: 


2) Xanadu Links; 
a) KANNAGI Sensors. 
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The Xanadu Document Model 


In most computer environments the term “document” is used to signify a discrete 
work, typically represented by a physical disk file made up of a stream of 
sequential, and often contiguous, bytes. These self-contained documents typically 
are closed systems, with static contents and clear boundaries represented by the 
edges of an imaginary piece of paper. : 


Xanadu documents differ significantly from this model; the following s sections 
detail each of these differences: 


1) Variants & Editions; 

2) Document Hicrarcuics: 

3) Virtuality; 

4) The Separation of State: Berts & Stamps; 
5) Publishing; 

6) Authorship; 


Variants & Editions 


Although Xanadu documents differ significantly from ordinarly electronic 
documents, both models have two essential elements: identity and state. 


A document’s identity is represented by the user’s perception of that document 
as a discrete, persisting entity (e.g., “The Acme Industries Marketing Plan”). The 
state of a document is represented by the ordering of the underlying bytes within 
its computer representation at any given time (e.g., the specific byte ordering in 
the file “Marketing Plan” as it exists at noon on Thursday). 


Different states are often represented by completely separate files and come to 
be known as different versions of the same document. In a curious confusion of 
terminology, these separate files are commonly referred to both as documents 
themselves, and as different versions of the same document. The ambiguity 
responsible for this confusion is potentially even more pronounced in the 
Xanadu environment, where document content is fluid and subject to frequent 
change. Accordingly, a new terminology is required. 


A document can evolve in two important directions: sequential and lateral. A’ 
sequential evolution occurs whenever changes are made to an existing document 
resulting in the creation of a new and different document. This new document is 
said to be a new edition of the onginal document, and follows it sequentially in 
time. 
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A lateral evolution occurs whenever an identical copy is made of an existing 
document. The new document, similar in content to the existing document, is 
said to be a variant and bears no temporal relationship with the pre-existing 
document. Typically, variants are created when one wishes to experiment with a 
document by editing a copy of that document without disturbing the original 
contents. The changes that are made to the variant may be saved from time to © 
time, resulting in the creation of new editions of that variant. 





Editions & Variants: A1 and A2 are editions of A. Bis a 
variant of A, and B17 is an edition of B. Cis a variant of B17. 


Document Hierarchies 


Any comprehensive document system must provide services appropriate to the 
various data types and data elements supported by that system (e.g., the ability to 
display and edit graphics documents, text documents, and so on). To do this, the 
system must be able to distinguish between documents made up of different 
underlying data elements. The Xanadu-Server distinguishes among the many 
kinds of supported data through the use of document types. These document 
types determine the kinds of services and operations available to individual 
documents. For example, documents of type Text and documents of type 
Vector-Graphic require very different editing services; the Xanadu-Server uses the 
document type of each to determine the appropriate services to provide. © 


Documents are frequently made up of several distinct components, each of which 
may represent a different document type. For example, a company’s Annual 
Report might include both text and graphics. The Xanadu-Server recognizes this 
kind of document as a grouping of sub-documents, collectively known as a work. 
Works can be nested to include other works, and are referenced by applications 
using work types. 


Every document-has associszted with ata Data Space a link Space. and.a Work 
Type Space. The Work Type Space can be thought of as a container that simply 
holds the work type of the document and identifies the work Gf any) with which 
the document is associated. The Data Space maintains information concerning the 
actual data of the document (e.g., the text characters, the bitmap’s bits, etc.), while 
the Link Space references all links associated with the document. 
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Virtuality 


Ultimately, all documents refer to data of some kind that exists at some physical 
location. Ordinary electronic documents typically store all of their contents at 
one location: within the document file itself. One of the features that distinguishes 
Xanadu documents is that they can be composed of elements of data residing at 
locations independent of each other, and independent of the document itself. 
The contents of a Xanadu document may reside at any number of sources, 
including multiple sources bearing no physical proximity to one another. 


New documents can be created out of completely new data (e.g., a user enters 
text into a newly created memo), or made up of bits and pieces of data from 
existing documents (e.g., a user copies a graphic from another document). Each 
underlying element or the data. (e:.9, cach character of text) is given space on the 
system and retains this space as long as the data remains online. 


New documents can be composed out of pieces of existing data by making virtual 
copies of the underlying data. Virtual documents can be thought of as frames that 
can be placed arbitrarily around existing chunks of data to form new 
representations of that data. These frames can be arbitrarily shaped and are not 
bound by the edges of an imaginary piece of paper. 


Document C 






Congress shall 
make no law 
respecting an 
establishment of 
relagqiuen,. of 
Prohibiting the 
free exercise 
thereof; 









Document B 


Document A 


Virtual Documents: The text on the left was created when document A 
was created. Document B is a virtual copy of document A and generates 
no new data. Document C is a new document made up of data from 
document A, and some new text. All of the documents share some data 
in common, but none of the documents replicates any of the data. 


Notice that the creation of virtual copies does not result in the replication of any 
underlying data. Because of the efficiency of the Xanadu algorithms, virtual 
documents are inexpensive in terms of both storage and retrieval costs. 
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The Separation of State: Berts & Stamps 


The Documents & Links Level maintains the distinction between document 
identity and state by providing separate objects for each. The Xanadu object 
representing document identity is the Bert, representing the end-user’s 
perception of a particular document. Berts are referenced using 
system-generated Bert IDs, guaranteed to be globally unique and persistent. 


The Xanadu object representing document state is the Stamp. Stamps are 
referenced using system-generated Stamp IDs, guaranteed to be globally unique 
and persistent. Since Stamps reference the state of a particular document, they 
only have meaning in the context of a particular Bert. 


Zu 6 


A Bert and a Stamp A Stamp on its associated Bert 


Documents sometimes undergo simultaneous revision by separate editors; there 
may exist, therefore, several different variants of a document, each having its own 
identity Cand therefore its own Bert). As each variant undergoes change it will visit 
new states, and, as these new states are visited, new and different Stamps will be 
generated representing each of the new states. Whenever the editor of the 
document elects to save any of these state changes, new editions are created. 


pe 
B BY B2 
B is an editing variant of A. B1 and B2 are the 


saved editions of B. 


Stamps are associated with exactly one Bert, and represent a “snapshot” of a 
particular state of that Bert; they do not -- indeed cannot -- change. 


5) 
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Any system that allows multiple parties to edit a single document must provide a 
solution for arbitrating editing conflicts. A typical solution is a mutual exclusion 
principle that grants edit permission to a single user, and thereafter precludes all 
others from editing the same document until the original editor has given up 
control of the document. This mutual exclusion model results in “lockout 
frustration”, forcing competing editors to wait until the pending editor has 
completed his work before gaining access. 


To resolve this issue, Xanadu uses virtual copies to implement a diverge-converge 
model. Under this model, competing editors can diverge their efforts. by 
spinning off variants and working on these virtual copies independently. When 
their work is complete, they then use Xanadu’s version compare facilities to 
arbitrate the convergence of their work. 


Although there is mutual exclusivity with respect to any particular Bert at a given 
time, the easy availability of virtual copies renders this limitation virtually | 
meaningless. This limited form of mutual exclusion is represented by the notion 
of “grabbing a Bert”. End users edit Xanadu documents by first “grabbing” the 
associated Bert using a mechanism detailed below (see “Manipulators’); the 
application is then said to “hold the Bert”. Possession of a particular Bert is 


mutually exclusive — so long as one user holds a particular Bert, no other user can 
hold it. 


Every Bert has associated with it a Stamp reflecting its current state, this state is 
represented in the Ben data structure Sy a Stamp 1D. Holding the Bert of a 
particular document enables the holder of the Bert to change the current state by 
simply substtuting a new Stamp ID. A new edition is created by simply 
generating a new state G.e., a new Stamp) and then changing the current state of 
the associated Bert to reflect this new state. To see a previous edition of a 
document, one simply associates the Bert with a previously saved Stamp ID 
reflecting the desired state of the document. 


As edits are made to a document, the system generates new Stamps representing 
each of the successive new states; in effect, the system automatically changes the 
Stamp ID of the Bert to reflect each new state change. It is the responsibility of 
the application to save those particular Stamps of interest to the end-user; Stamps 
not specifically stored away are irretrievable and will be disposed of by the 
system as new Stamps are generated. Stamps which have been saved can later be 
used to retrieve previous editions of interest. 


Having Read permission on a Xanadu document means that you are able to know 
the current state of the associated Bert; having Edit permission means that you are 
able to change the current state of the Bert. For a detailed discussion of document 
permissions, see “The Permissions System”, below. 
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Notice that you can trace through a document’s history using previously saved 
Stamps. In fact, this is the mechanism by which Save, Undo, Revert, and other 
state-related editing operations are accomplished in the Xanadu environment. To 
update the current state of a document, for example (a Save operation), an 
application simply ops the Bert to the state represented by the current Stamp. 
This has the dual effect of re-defining the current state of the Bert and creating a 
new edition. 


Hopping a Bert is an act that can be visualized as the movement of a Bert from 
one location to another, and its consequence is the creation of a new Stamp 
representing a new current state for the document. When an application hops a 
Bert, it is in effect associating the identity of that document with a new 
representation of state. 





_- 


Hopping a Bert to a new Stamp 


When a Bert is hopped from one Stamp to another, it leaves the old state and 
becomes associated with the new state Gvhich then becomes the current state). 
You might imagine this process in reverse G.e., hopping the Bert back to an old 
state) but strictly speaking this never happens. When an application attempts to 
hop a Bert from its current state to a previous state, the system creates a new 
Stanip representing the prior state. and then Hoos the Ber to this new Stamp: tie 
movement of Berts is always forward through the chain of newly created Stamps. 


The following example illustrates a typical editing scenario from an end-user’s 
perspective. Imagine a document entitled “Tech Manual”, residing on a 
Xanadu/Server accessible to the members of a small workgroup. The document 
has undergone extensive revision, and this particular instance represents the 
authoritative current version of the work within the department. Suppose that 
the manager of the department decides to make a small change based on some 
new information. 
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The manager settles on an editing strategy that involves: 1) opening up the original 
document and holding on to it so that it can’t be changed by others; 2) making a 
private editing copy; and 3) making the desired changes to that copy. When he’s 
satisfied with his changes he’ll update the original document to reflect these 
changes, and then release it back to the workgroup. 


He begins by running his frontend application, logging in to the Xanadu-Server, 
and then initiating a request to open the document entitled “Tech Manual”. The 
application attempts to grab the Bert representing this document by providing a 
previously stored BertID. Since no one else is holding this Bert, the attempt 
succeeds. By examining the Bert ID of the opened document and comparing it to 
the previously stored Bert ID of the original, the application is able to determine 
that it has succeeded in opening the original Gf the Bert IDs had not matched, the 
application would have reported that it had returned a virtual copy). 


The application’s display interface routines then compose the document and 
display it on the manager’s screen. He indicates a desire to work on an editing 
copy of the document, and the application obliges by creating a virtual copy of 
the document and presenting this new variant on the manager’s screen. Notice 
that a new Bert has been created and that the manager is now holding onto two 
distinct Berts. All of this is handled transparently by the application, and from 
the manager’s perspective all he sees is one document, although he realizes that 
he’s working on a copy. 


The manager then proceeds to make changes to the variant. At various points he 
elects to preserve these changes by issuing a “Save” command to his application. 

In response to each “Save” request, the application hops the variant’s Bert to the 

Stamp representing the current editing state. This happens several times during 

the session and in each case the application creates a new edition by hopping the 
variant’s Bert to a newly created Stamp, reflecting the document’s travel through 

successive States. 


Variant of 
"Tech Manual!” 


Original "Tech Manual” 





Successive editions 
of the variant 


Editing a variant while holding onto the original Bert 
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Unknown to the manager, a co-writer in his office decides to update the manual to 
reflect the same new information Gve will assume that she is authorized to do so). 
She runs her application, logs into the Xanadu-Server, and then attempts to open 
the document entitled “Tech Manual”. Her application attempts to grab the Bert 
but fails, since it is currently being held by the manager. At this point, her 
application presents her with a virtual copy of the document for her to 
independently edit G.e., her own variant with its own private editing Bert). She 
elects tO wait to see what changes are made to the original document, and leaves 
for lunch. 


Meanwhile, the manager decides that he’s satisfied with his changes to the variant, 
and decides to update the official version of the document to reflect thsese 
changes. His application hops the Bert of the original document to a new Stamp 
representing the current state of the variant editing Bert. The effect is to change 
the current state of the original document to match exactly the current state of the 
editing variant. 





The orginal Bert is hopped to a new Stamp 
corresponding to the current state of the variant. 


Satisfied that his job is complete, the manager quits his application and goes out to 
lunch. His application releases both the original and the variant Bert, and logs him 
out of the system. | 


When the co-writer returns from her lunch, she learns that the document she had 
asked to edit is now available for editing (the Bert has become free). She opens 
the document (grabs the Bert), but the document she now sees is the version that 
was updated in her absence. Noting that her modifications are no longer 
necessary, she logs out of the system and quits her application. 
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This deliberate coupling and de-coupling of Berts and Stamps is the essence of 
document manipulation in the Xanadu environment. For more specific 
information on Bert and Stamp manipulation, see “The Manipulator Interface’, 
below. 


The time may come in the life of a document when no further edits are desired or _ 
anticipated. At that point, anyone with Edit permission on the document may 
elect to freeze the Bert. Freezing the Bert has the effect of finalizing the 
document such that no one can thereafter hop the Bert -- in effect, the Bert 
marries the Stamp:. Divorces are not available to frozen Berts; the act of freezing a 
Bere4s 1nreversibic. 


Berts are usually frozen to permanently memorialize an event which itself cannot 
logically be reversed. For example, one might wish to print a copy of a document . 
and title the particular edition printed “Doc Printed 10-13-89”. As long as this 
document is intended to reflect the state of the document as printed on October 
13, 1989, it makes no sense to change its contents at any time in the future; this 
case presents an ideal candidate for freezing the Bert. 


Freezing a Bert is accomplished by altering the permissions associated with the 
document such that it becomes irrevocably uneditable. For a detailed description 
of edit permissions, see “7he Permissions System’, below. 


Publishing 


“Publishing” is a term loaded with meaning in both the electronic and 
non-electronic document worlds -- we will not’attempt to define it here. One of 
the many possible meanings of interest to Xanadu users, however, is the act of 
making 2 document available to be read by others. This is accomplished in two 
Steps: eranting read permission to the intended readers, and creatine a-path to the 
document allowing these readers to find the document. For a detailed description 
of the granting of read permission, see “The Permissions System”, below. 


There are several ways to create a path to a document. One technique involves the 
creation of links and is discussed below. Using this technique, Xanadu users can 
set up their own electronic mailboxes , and watch these places for the arrival of 
new documents as they are published. 


As another example, a Xanadu community could establish a Public Bulletin Board 
and make it known that new public announcements will be found there. 
End-users could then establish their own public bulletin boards and mailboxes, 
gnG@ announce-this fact on tie Public Bulletin Board. 
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Authorship and Endorsement 


The collaborative environment supported by Xanadu raises new questions 
concerning the notion of authorship. Who is the “author” of a virtual document 
edited by three users and made up of components taken from ten other 
documents? Although it is possible to occasionally identify a specific user as the 
Originator in some sense of a specific sequence of bytes, the concept quickly loses 
meaning as other users create virtual copies of those bytes and begin editing, 
linking, and otherwise expanding on the material. 


Xanadu provides endorsement as a more relevant and useful indicator of 
document accountability. Endorsement is not completely synonymous with 
“agreement” (although in practice this will frequently be the case), but rather is an 
assertion that one desires to be associated in some way with the document or 
passage endorsed. A law professor, for example, might wish to endorse a 
particular Constitutional Law treatise, even though her intent is to use this treatise 
as an example of extraordinarily bad law. 


Endorsements “stick” to Berts, and are not copied when virtual copies are | 
generated. This prevents one person’s endorsement from being associated with 
the unforseeable content of future virtual copies. 


Endorsement is not limited to the editors of a document; anyone able to read a 
document can endorse it. Endorsers with read-only permission have an implicit 
stake in the document, even though they have no say in its contents, since their 
endorsement is apparent to anyone else who can read it. 


In the Xanadu environment, then, the “author” of a document is anyone having 
Edit permission on the document and who has also endorsed the document. 
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Xanadu Links 


This section describes Xanadu links and how they differ from links used in other 
hypertext systems. You should be familiar with the Xanadu Document Model 
prior to reading this section. 


Links are objects created by end-users to assert relationships between the various 
components of their data. In some cases links provide additional substantive 
meaning to the original data, as in the case of a link to additional reading material | 
on a similar or related subject. Links are also used as navigational aids, providing a 
direct path to a particular repository of data independent of the data itself, as in 
the case of a link to a specific user’s electronic mailbox. Finally, links are used to 
manage document-level housekeeping issues, such as the mapping of particular 
portions of text to style and attibute information, or other related formatting 
issues. 


Applications can determine if a particular document contains any links; links so 
discovered can then be followed to the material they reference. Additionally, 
applications can BackReference a document to determine if any part of it is 
referenced by links contained in other documents; links discovered this way can 
then be followed back to their source. Notice how the omni-directionality of 
links allows their traversal in any direction; Xanadu links have no inherent 
directionality. 





Document "A" Document "B” 


Following a Link faund in document "A" to the 
material in document "B" 


Document "C” Document "D" 





Document "A” 


BackReferencing document "A" reveals links from documents "C” and "D". 
The links can then be followed from "A" to "C”, or from "A” to "D”. 
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Applications create links in three steps: 


1) Tne mecessary Endsels are createa. 
2) A home document is designated and a request is made for a link; and 
3) The link is added to the Link Space of the home document. 


For additional information on the link creation process, see “The Manipulator 
Interface’, below. 


Following & BackReferencing 


Because Xanadu links are omni-directional, it’s important to understand clearly 

' the nature of link directionality. Xanadu links do not “point” in any particular 
direction. Rather, they are like the interconnecting cable in a data network, 
enabling traversal from any one LinkEnd to any other. When a user encounters a 
link in a document he is reading, he may elect to travel to the other end of the link 
to see what’s there. This act of traversing a link from one LinkEnd to another is 
called “following the link”. 


It is also possible while reading a document or passage to determine whether or 
not there are any links in the information pool having a LinkEnd in the particular 
document or passage being read, irrespective of the location of any such link’s 
home document. This operation is called “BackReferencing”, and does not result 
in traversal of the links so Jocated, but simply identifies them. After these links 
have been identified they can of course be followed into their EndSets. 


For more information on the Follow and BackReference operations, see “The 
Manipulator Interface’, below. 
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Sensors 


[Sensor documentation is under construction.] 
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The Manipulator Interface 


The following section describes Manipulators and how they are used by frontend 
applications to perform operations on the various Xanadu objects. In order to 
understand what those objects are, you should have first read the “Documents & 
Links Level” section. In order to understand the material relating to permissions, 
you may find it helpful to first read the “Permissions” section. 


This section begins with a general discussion of what Manipulators are, and what 
services they provide, and continues with a brief description of two important 
Manipulators, Hands and Waldos, and some of the operations they support. 


' Frontend applications do not directly manipulate Berts or Stamps. Instead, they 
use various kinds of Manipulators. The Manipulator object is an abstraction which 
provides the protocols necessary for interaction with Berts, Stamps, Links, and 
the other Xanadu objects. Various kinds of Manipulator objects can be created 
based on the general Manipulator abstraction, each having its own specified 
protocol. In this way, the Manipulator abstraction facilitates the easy creation of 
new objects having their own specialized operations. 


Additionally, Manipulators provide the mutual exclusion mechanism necessary for 
certain operations. As noted above, grabbing a Bert is a mutually exclusive 
operation which, when accomplished, precludes any further grabbing of the 
same Bert until after it has been released. Manipulators are the objects which 
enforce this mutual exclusion principle. 


Manipulator objects perform a number of type-checking and type endorsement 
operations on the objects with which they interact. Because of these certification 
processes, and because of the protocol boundaries they enforce, Manipulator 
objects also help maintain the consistency of the underlying data upon which they 
operate. Frontend applications can use Manipulator objects, for example, to 
perform operations on the various pieces of a complex work and remain 
confident that all of the pieces will behave as expected. 


All Manipulators are session-level objects created and disposed of by the system 
at the request of, and during the life of, a frontend application. 


Hands 

The simplest kind of Manipulator object is the Hand. Hands are the exclusive 
means of access tO. berts im the backend: all-operauons on -Berts must be 
performed through a Hand. In addition to ensuring mutual exclusion, the 
imposition of Hand protocols for the manipulation of Berts removes the 
responsibility for the enforcement of permission boundaries from Berts, and 


places that responsibility with the Hand object. Hands are referenced throughout 
the system by globally unique Hand IDs. 
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There are three different kinds of Hand objects currently supported: 


1) Actual Hands; 
2) PhantomHands; and 
3) Subliands. 


Actual Hands are the simplest kind of Hand object and provide only one 
operation, FetchGrab. Given a KeyMaster and a Bert ID, FetchGrab will return a 
Hand on the Bert. For example, in the course of a document editing session, a 
frontend application might ask a KeyMaster to grab a particular Bert by sending it 
the FetchGrab message along with the Bert ID of the document. If the operation 
fails for some reason, FetchGrab returns Null. If successful, FetchGrab returns a 
Hand and that Hand is subsequently used by the application to manipulate the 
document: 


PhantomHands are used for temporary manipulation and do not result in changes 
that persist across sessions. They do not directly manipulate Berts, and are 
commonly used to keep track of intermediate transactions of temporary interest 
only. 


SubHands are used to manipulate the pieces in a complex work and are 
responsible for propagating certain changes throughout a document hierarchy. 
When hopped, for example, a SubHand updates the information necessary to 
reflect the hop transaction, and then hops the parent hand Cwhich may in turn be 
another SubHand and thus result in further hops). - 


Waldos 


Another important Manipulator object is the Waldo. Waldos mimic their real- 
world counterparts by facilitating the safe remote handling of delicate objects, and 
can be visualized in the same way: as mechanical arms with hands at the end. 
Unlike Hands, Waldos can wrap other Manipulator objects Gncluding other 
Waldos), and thus provide a thematically related and restricted set of operations 
and protocols for the handling of specific types of data. Waldos are referenced 
throughout the system by globally unique Waldo IDs. 


In addition to providing protocol boundaries, Waldos offer far more utility to the 
frontend application developer dealing with a specific data type. For any given 
data type, a corresponding Waldo can be created offering an easy and secure 
interface to that data type. Specific services applicable only to the underlying data 
type can be offered. For example, a text Waldo could provide charcter-based 
text-editing capabilites, while a digital sound Waldo could provide audio-specific 
editing features. Since Waldos can wrap other Manipulators, including Hands, a 
Waldo can use a Hand to perform the Bert hopping necessary in the course of an 
editing session. 
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Every Waldo object provides the following operations: 


1) BackReference — Returns the set of all Bert IDs or Stamp IDs that refer 
to this Waldo’s ID. The operation can be filtered for particular 
endorsements. 


2) Copy -- Returns a new Waldo of the same type with the same contents. 
3) Top -- Returns the outermost Waldo in a wrapping hierarchy. 


4) ReplaceWith -- Replaces the contents of the Waldo with those of another 
Waldo. This is the hopping mechanism. 


5) UnWrapped -- Deletes this Waldo and returns what it is wrapping. 


6) WaldoMaker -- Returns an object that can be used to make another 
Waldo similar to this one. 


Waldo Types 


The IndexedWaldo is an object of type Waldo, and adds additional protocol for 
table-like access to data. Get, Fetch, and Store operations are supported, as well 
as Operations that create tables out of data described by a region parameter. 
These tables can be compared, and mappings can be produced specifying how to 
transform the IndexedWaldo’s data into the data referenced in the comparison. 
This is the basis for the backend’s powerful version compare facilities. 


An IndexedWaldo’s BackReference and Copy operations also accept a region 
parameter. 


Two important kinds of IndexedWaldo are the IndexedWrapper and the 
RestrictledWrapper. The IndexedWrapper passes all messages it receives along to 
the IndexedWaldo that it wraps, and provides facilities for editing zero-based, 
contiguous arrays of data (e.g., text). 


The Restricted Wrapper limits access to the IndexedWaldo that it wraps, and is 
typically used to manipulate documents and links. Specialized messages are 
available to enable the creation and editing of documents and links 


Using Waldos to Manipulate Links 


Applications perform operations on documents using DocumentWaldos (a type 
of RestrictedWrapper Waldo). The information regarding a document’s links is 
obtained by sending a message to the document’s DocumentWaldo, which then 
examunes the dink Space of ie document io create and reich an appropriate 
LinkWaldo. Applications then use the returned LinkWaldo to perform 
operations on the link. 
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Applications create links in three steps: 


1) WRe necessary Enasets are created: 
2) A home document is designated and a request is made for a link; and 
3) The link is added to the Link Space of the home document. 


EndSets are created by sending a message to a DocumentWaldo instructing it 
either to create a LinkEnd on a given region of data, or to create a LinkEnd on 
itself. The region may consist of any range, or combination of ranges, within the 
Data Space of ne document, 


Once a home document has been decided upon, an application creates a link by 
sending a message to the home document’s DocumentWaldo, which then returns 
a Link Waldo to the application. The DocumentWaldo gets the Link ID from the 
Link Waldo, and inserts this into the home document's Link Space. Again, the 
application then uses the LinkWaldo to perform any operations on the link itself. 


Applications create a Type Space EndSet by creating a new document and then 
passing the document’s Bert ID to a Link Waldo along with a request for a 
LinkTypeDoc Waldo (a kind of DocumentWaldo). The returned LinkTypeDoc 
Waldo is then used to edit the type document as necessary. 


Using Waldos to Follow Links 


Before an application can follow a link it must first be able to locate the link in a 
document. Applications can quickly identify all of the links whose homes are in a 
given document by sending the FindLinksContaining message to the associated 
DocumentWaldo,. The request can be filtered for certain endorsements C.e., 
particular authors), and specific regions (e.g., a specific text range). The 
Document Waldo returns the set of LinkWaldo IDs for every link passing the 
supplied filters. Individual links can then be followed by sending a Follow 
message to the associated Link Waldo and indicating the specific EndSet to be 
visited. 


Imagine that an end-user has opened a document to be read. After opening the 
document the application might send a FindLinksContaining message to the 
associated DocumentWaldo to determine all of the links whose homes are in the 
document and which pass the user’s filters. The document could then be 
displayed along with its associated links in whatever manner deemed appropriate, 
according to the EndSet context information. If the user subsequently decided to 
follow a particular link, the application could then send a Follow message to the 
appropriate LinkWaldo, specifying the EndSet at the other end of the link as the 
destination. The LinkWaldo would then return as its result a DocumentWaldo for 
the document containing the linked material, along with a region specifying the 
exact location of the linked data within the document. The application could then 
use this information to display the linked material as appropriate. 
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As noted above, applications perform a BackReference operation by simply 
sending a DocumentWaldo the BackReference message. Any individual links thus 


identified can then be followed by sending the Follow message to the appropriate 
LinkWaldo. 


Conchision 


Manipulators provide an interface to the various data objects supported in the 
Xanadu environment, and define the protocols necessary for handling these 
objects. By providing these protocols, they simply the programmer’s job; by 
restricting the protocols, they maintain the integrity of the Xanadu data objects. 
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The Permissions System 


This section describes the Xanadu Permissions system. It begins with a detailed 
description of Clubs and their attributes, and then briefly describes the various 
objects used to manage Clubs. You can read this section at any time, without 
having read any prior material. 


Clubs 


The interaction between Xanadu end-users and documents is governed by a 
system of permissions. There are three important permissions a user can hold 
with respect to any particular document: Read permission, Edit permission and 
Endorsement permission. The mapping between a particular document and the 
permissions available to particular users with respect to that document, is 
accomplished through the mechanism of Clubs. 


Clubs may be thought of as discrete collections of end-users (either as individuals 
or as groups of individuals); in fact, Clubs provide the exclusive representation of 
end-users within the Xanadu environment. End-users refer to Clubs by name, 
using the name provided by their local system administrator at the time of a 
Club’s creation. Application developers reference Clubs in their code using Club 
IDs generated by the system when the Club is created. Because of the need to 
preserve document permissions in a multi-user environment indefinitely, Club 
IDs are globally unique and eternally persistent, surviving even if the underlying 
Club has somehow ceased to exist. 


Clubs interact with each other according to the nature of their relationship to each 
other. The most fundamental kind of relationship is membership. Club 
membership entildes the members to exercise any Of the permissions associated 
with the Club. For example, a Club could be given read access to a particular 
document; in this case all members of the Club would be permitted to read the 
document. 


All Clubs maintain an internal list of their membership. New Clubs are created 
initially listing their creator as their only member, and new members can be 
added at anytime thereafter. Each newly added member is fully entitled to all of 
the benefits associated with the Club; there are no seniority advantages. 


Membership can be infinitely nested; that is, a Club can list as its members a set of 
other Clubs. any one Of which could in turn list another set of Clubs, and soon. 
Chabs: can, be members of any number of other Chibs -- there is no membership 
limit. 
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Club A is listed as a member of Club B 


Club membership does not imply inclusion. It’s possible, for example, for two 
Clubs to list each other in their respective membership lists. Clubs that are 
members of other Clubs continue to maintain their own wholly independent 
identity. 


Clubs A & B list each other as members 


Control Authority and Read Authority 


There are two important permissions a user can hold with respect to any 
parucular Club: control authority and read authority. Club control authority 
provides a distinction between those who can set and alter the attributes of a 
given Club, and those who cannot. Club control empowers the controlling Club 
to exercise authority over the controlled Club in a number of important respects. 


Clubs must have exactly one controlling Club. All Clubs are created initially 
self-controlling to allow their creators freedom to set their initial attributes, but 
this primitive state can later be altered to place control outside the Club. 


Club read authority provides the ability to read a Club’s membership list Ceither 
its own list, or some other Club's list). Just as Clubs are created iniually 
self-controlling, all new Clubs are created with a self-read capability, allowing all 
initial members to read their own membership list. This self-read capability can 
be revoked at any time by members of the controlling Club. 





Dias 


Indicates self-controlling --> ‘. <-- Indicates self-reading 


' 
7 





Clubs A and 8 are self-controlling and self-reading 


Control authority and read authority are independent ideas; a Club can exercise 
read authority over another Club without exercising control authority. However, 
the ability to read a Club’s membership list is itself a native attribute of control 
authority, independent of any explicit read authority. 
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Other actions specifically authorized by Club control (and discussed below) are: 


1) The ability to edit the controlled Club’s membership list; 

2) The ability to iniuate an Edit or Read distinction on the controlled Club; 
3) The ability to set the controlled Club’s optional Home document; and 
4) Management of the Club’s Locksmith. 


Since any member of a self-controlling Club can alter its own membership list, 
surprising results are possible. Two self-controlling Clubs could elect to list each 
other as members of the other, for example, and this would enable any member 
of either Club to delete any or all of the other members from either Club 
including the evicting Club member himself!) Rather than attempt to forsee and 
prevent such anomalies, the Xanadu Permissions System maintains an audit trail 
capability allowing users to track all control actions. 


The members of a Club might find it desirable at some point to revoke 
self-control status from the Club. Or, they may wish to enable members to read 
their own membership list without enabling them to change that list. For 
example, a user might wish to send a memo to a group of recipients such that 
each recipient could determine who else had received the memo (the traditional 
carbon copy). He could of course manually include this information in the body 
of the memo itself, but there would be no way for any of the recipients to verify 
the accuracy of the list: 


These objectives are supported in the following manner: an additional attribute of 
control authority is the ability to initiate two distinctions: a membership vs. 
contro! distinction (hereafter a “control distinction”), and a membership vs. read 
distinction Chereafter a “read distinction”). 


When a controlling member elects to make a control distinction, the effect is to 
create a new Club having control authority over the original Club, with both Clubs 
listing each other as members of the other. The original Club retains the original 
Ciibp Dy . Because DotneGiubs list. cach. Otier. as memocrs oF ine omer no 
member of the original Club has lost any privileges previously enjoyed. Notice, 
however, that the original Club is no longer directly self-controlling, even though 
its members can still exercise control authority at this point by virtue of their 
membership in the new, controlling Club. | 
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Club A after a control distinction 


This process can be repeated indefinitely, successively providing new levels of 
indirect control over the transformed Clubs. By manipulation of the 
membership lists in such Club hierarchies, controlling members can be 
separated and distinguished from non-controlling members. 


The initiation of a read distinction has the similar effect of creating a new Club. 
Again, both Clubs list each other as members of the other and the original Club 
retains the original Club ID. Because both Clubs list each other as members of 
the other, no member of the original Club has lost any privileges previously 
enjoyed. And although the original Club is no longer directly self-reading, its. 
members can sull read their membership list by virtue of their membership in 
the newly-created read Club. 





Club A after a read distinction 
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The initiation of one distinction is independent of the other. It’s possible, for 
example, to create a Club consisting of members able to read, but not edit, their 
membership list (a control distinction without a read distinction); this is the 
traditional “carbon copy” group. Such a Club could be given read access to a 
document, and every member of the Club could see who else also had that access. 





Club A is a “blind carbon-copy” Club; its members 
can neither read nor edit their membership list. 


It’s equally possible to create a Club consisting of members unable to read or edit 
their membership list (after a control distinction and a read distinction); this 
results in the creation of a “blind carbon copy” group wherein no member of the 
group can determine who else is a member of the group. 





Club A is a "blind carbon-copy” Club; its members 
can neither read nor edit their membership list. 
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In order to restrict unauthorized assertions of Club membership, all Clubs have a 
Locksmith associated with them; Locksmiths are responsible for the installation 
of a particular security lock for the Club. There are three types of Locksmiths 
available to Clubs, corresponding to the three kinds of security locks supported: 


a) Password Locksmiths; 
b) Wall Locksmiths; and 
¢c) Boo Locksmiths. 


The type of Locksmith in place in a given Club is declaratively obvious to anyone 
Who can sée tie Club: | 


Password Locksmiths install locks that can only be satisfied with some kind of 
password; Wall Locksmiths install locks that cannot be satisfied by any means; 
Boo Locksmiths install locks that can be satisfied by anyone (Gust say “boo”). New 
Clubs are initially created with a Wall Locksmith. While this might seem odd, 
remember that new Clubs are created self-controlling and therefore able to 
change their Locksmith immediately, if desired. 


As noted above, Club membership entitles a member to whatever benefits are 
associated with that Club. If Club A is a member of Club B, then any member of 
Club A can exercise any benefits associated with Club B by virtue of that 
membership. But it’s also true to say that Club A itself-- as opposed to the 
members of Club A -- can enjoy these benefits. Club association, then, can be 
asserted either directly (‘I am Club A”), or indirectly “I am a member of Club A”) 
and the results are exactly identical. It is through satisfaction of the Club’s lock 
that Club identity is directly established — anyone who can satisfy the lock of a 
given Club can, in effect, assert that he is that Club, and therefore entitled to 
precisely the same benefits available to members of that Club, even if he is not 
himself a member. 


All Clubs are created initially without a Home document and it is up to the 
controllers of a Club to designate one, if desired. Home documents typically are 
used as a Starting point for navigating the system, but may contain any kind of 
information, including directories of other Clubs or documents accessible to the 
members of the Club. 


The permissions relating to Xanadu documents are maintained by two important 
Clubs associated with every document: the Read Club, which lists all members 
having Read permission with respect to that document; and the Edit Club, which 
lists all members having Edit permission with respect to that document. 
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The Read and Edit Clubs of a document should not be confused with the Clubs 
that are created after the initiation of a control or read distinction. Note, however, 
the parallels between document Edit permission and Club control authority on 
the one hand, and document Read permission and Club read authority on the 
other. Just as control authority confers a native ability to read the controlled 
Club’s membership list, membership in the Edit Club of a document 
automatically confers a native ability to read the document, independent of 
membership in the Read Club. 





A typical document and its associated Clubs 


Membership in a Club does not imply the consent of the members to be listed as 
members; the controller of a Club can list as members any other Club in the 
system without the consent or knowledge of that other Club. Members can, 
however, determine all of the Clubs that explicitly list them as members. Implicit 
memberships G.e., membership by virtue of membership in a Club itself 
explicitly listed) can also be determined by a simple iteration through each of the 
explicitly listed Clubs. 


KeyMasters & Chub Managers 


The Club system described above specifies how groups of users interact with 
each other and how those users obtain access to documents. Applications use a 
further set of abstractions for actually administering these relationships. 
KeyMasters and Club Managers are the session-level protocol objects used by 
applications for the express purpose of managing Club-related activities during a 
Xanadu session. 


There are two kinds of KeyMasters: Club KeyMasters and Composite KeyMasters. 


- Club KeyMasters can be thought of as sentries holding the key to a particular Club. 


Any given Club KeyMaster holds exactly one key, and this represents knowledge 
of the permissions G.e., Club memberships) associated with the Club for which it 
was created. Club KeyMasters can be created for any Club accessible to a user: 
this allows a user to navigate through the system using different sets of 
PCiimissions. 
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Composite KeyMasters are used to handle user-specified groups of Clubs; the 
“keys” they hold in this case represent the union of all permissions associated 
with each of the Clubs forming the aggregate group. 


| Composite 


A Club KeyMaster and a Composite KeyMaster 





KeyMasters provide applications with a number of important services. Among 
other things, a KeyMaster: 


1) Returns the Bert ID of the Home document Gif any) associated with its 
Club; 7 

2) Opens Gocuments 2ccessibie 10.1ts Club: 

3) Creates Club Managers; and 

4) Creates new KeyMasters for other Clubs. 


As noted above, applications use KeyMasters to access documents, including a 
Club’s Home document, the usual! starting point for navigation of the system. 
Since KeyMasters are needed to create other KeyMasters, this raises the obvious 
question: how does one begin the process of locating and opening Xanadu | 
documents? | 


In order to provide for initial access, three important Clubs are shipped with 
every new Xanadu system: the Admin Club, the Public Club, and the Null Club. 





Wall Locksmith Boo Locksmith Password Locksmith 


The Null Club, the Public Club and the Admin Club 
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The Admin Club is typically set up and administered by the system administrator 
for the site, and is shipped with a Password Locksmith using a private password 
supplied by the Xanadu Operating Company. Like any other new Club, the 
Admin Club has self-read authority and is self-controlling. 


The Public Club comes equipped with a Boo Locksmith and self-read authority, 
but lists no members. This allows anyone to assert that he is the Public Club, and 
to see that anyone else can also assert this fact (since the presence of the Boo 
Locksmith is declaratively obvious). The Public Club maintains a Home document 
that applications use for their initial entry to the system, as described below. The 
Admin Club is listed as a member of the Edit Club of this Public Home document. 
The Public Club is controlled by the Null Club, and has read authority over the 
Null Club. 


The Null Club is self-controlling but not self-reading. It lists no members and has 
a Wall lock installed. Because it is self-controlling and without members, it can 
never be altered in any way by anyone, including the system administrator. 


These three Clubs combine to form a secure entry-level Club system that can be 
accessed initially through the Public Home document. Since the Admin Club is a 
member of the Edit Club of that document, the system administrator Cor, 
whoever is responsible for administering the Admin Club) is free to alter that 
document as necessary to allow other users to navigate the system. 


The backend maintains a persistent Public Club KeyMaster that is available to 
bootstrap users into the system. This Public Club KeyMaster is accessed 
immediately after logging onto the Server, and is used to determine the Bert ID of 
the Public Home document. The Public Home document contains a directory 
mapping all system user names to their respective Club IDs (the system 


administrator maintains this list”. 


Armed with a particular Club ID corresponding to the Club, applications can 
create their own Club KeyMaster by sending an appropriate message to the Public 
KeyMaster. If the application succeeds in satisfying the Club’s lock, the new 
KeyMaster is created and returned to the application for its use. 


Notice that applications interact with locks, not Locksmiths. Locksmiths are 
system objects responsible for the managment and installation of particular kinds 
of locks. Locks themselves are generated by the system at the request of a 
particular Locksmith. 


Club Managers are the objects used by frontend applications to execute control 


acuions with respect to 4 controlled Club: they accept messages to exercise each 
of the control actions discussed above. 


x 
Unix users may recognize this as analagous to the “/etc/passwd” file. 
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Applications obtain Club Managers by passing a Club ID to an existing KeyMaster 
and requesting that a Club Manager for that Club be created. If the KeyMaster 
used for this purpose “holds the keys” for that Club G.e, the KeyMaster is able to 
confirm that the Club ID passed by the application belongs to a Club with respect 
to which the KeyMaster’s Club can exercise control), then a valid Club Manager 
will be returned to the application. 


Club Managers are also returned by the system when a new Club is created. This 
allows the Club creator to immediately begin setting up the Club’s attributes as 
necessary. 


A Final Note on Permissions 


It's worth noting that in the Xanadu environment, Read permission corresponds 
closely to the realities associated with allowing someone to read an ordinary non- 
electronic document. That is, Read permission can never be revoked with 
respect to a particular edition of a document, and this corresponds to the 
realization that once you’ve let someone read a particular edition of a document, 
it's impossible to assure that they haven’t taken steps to permanentuy record the 
contents of that edition (by memorizing it, copying it, etc.). 


Read permission can be revoked with respect to the document itself, and in this 
case the effect is to prevent the reading of all future editions of the document. 
However, once particular bits have been read, they can never be withdrawn from 
heir Téacders. 


In practice, users of the Xanadu/Server will develop their own conventions 
concerning the intended scope of their documents, just as they currently do with 
respect to ordinary documents. The Xanadu version of the “Company 
Proprietary” rubber stamp will bear precisely the same force that its manual 
counterpart does today. 


Ultimately, no machine-based system can provide a protection structure having 
the full richness of the contractual relationships possible between humans. What 
the Xanadu/Server does provide, however, is an environment that a) handles most 
of the major distinctions, and b) provides a comprehensive system of 

_ permissions combined with accountability to the members of that system. 
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Appendices 


Appendix A: Hardware Platforms Supported 
[ Forthcoming ] 
Appendix B: Networking Architectures Supported 


[ Forthcoming ] 


Appendix C: Software Development Environments Supported 


Standard C Programming 


[Forthcoming] 


Object Oriented Programming: C++, K++, Smalltalk 


[Forthcoming] 


Appendix D: Suggested Readings on Hypertext 
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